HPAVC/HPAVC CD-ROM.iso/pc/HTOCRK81.ZIP/HTOCRK81.TXT

Text File | 1996-05-20 | 18.1 KB | 624 lines

                     HOW TO CRACK, by +ORC, A TUTORIAL

---------------------------------------------------------------------------

               Lesson 8.1: How to crack Windows, an approach

---------------------------------------------------------------------------

                                [WINPGP.EXE]

                   --------------------------------------

--------------------------------------------------------

     SPECIAL NOTE: Please excuse the somehow "unshaven"

     character of the windows lessons... I'm cracking the

     newest Windows '95 applications right now, therefore

     at times I had to add "on the fly" some corrections to

     the older Windows 3.1 and Windows NT findings.

                "homines, dum docent, discunt".

---------------------------------------------------------

->   1st THING TO REMEMBER

The NE format does give every windows executable the equivalent

of a debug symbol table: A CRACKER BLISS!

->   UNDOCUMENTED DEBUGGING

One of the many feature of Windows based on undocumented

foundations is the "ability to debug".

A word about undocumented functions in the MS-Operating Systems:

Microsoft manipulates its rule and domination of the operating

systems in use to day (MS-DOS, Windows, Windows '95) with two

main wicked aims:

1)   getting the concurrence completely bankrupt (that's the

     scope of all the using of undocumented functions and

     CHANGING them as soon as the concurrence uses them). The

     battle against Borland was fought in this way.

2)   getting all future "programmers" to use windows as a "black

     box" that only Microsoft engineers (if ever) can master, so

     that everybody will have to sip the ill-cooked abominations

     from Microsoft without ever having a chance to alter or

     ameliorate them.

Strange as it may seem, only the sublime cracker community fights

against these intolerable plans. All stupid governments and

lobbies -on the contrary- hide behind the fig-leaf of the

"market" "freedom" in order to ALLOW such heinous developments

(I'm speaking as if they were capable to opposing them even if

they wanted, which they do not. Be assured, they couldn't anyway,

"Governments" are deliberately MADE to serve Gates and all the

remaining suckers, and lobbies are the shield of feudalism. You

can forget "democracy", the only rule existing is a malevolent

oligarchy based on money, personal connections, defect of

culture, lack of knowledge and dictatorship of bad taste through

television in order to keep the slaves tamed... enough now...)

The windows situation is particularly reminiscent of the older

situation in DOS, where for years the key "load but don't

execute" function, used by debuggers, such as [DEBUG], [SYMDEB]

and [CODEVIEW], was "reserved" by Microsoft.

     The windows debugging library, WINDEBUG.DLL, a number of

undocumented functions and even the interface it provides are

undocumented! The WinDebug() function is used by all available

windows debuggers, including [CVW] (CodeView for Windows), [TDW]

(TurboDebugger for Windows), [Multiscope] and [Quick C for

Windows] (the last two are GUI, not text debuggers. The use of

WinDebug() doesn't show up in MAPWIN output 'coz debuggers link

to it at run-time via the amazing GetProcAddress() function.

     WinDebug() is a hacked 32-bit version, for the old Windows

3.0, of the poorly documented DOSPTrace() function from OS/2 1.x

(study these older Operating Systems! Studying the past you'll

understand EVERYTHING! Sometime I think that the only way to hack

and crack correctly is to be more a software historian than a

programmer... fac sapias et liber eris!). DOSPTrace is, in turn,

based on the ptrace() function in Unix.

     Like DosPTrace(), WinDebug() takes commands such as Go,

Single-Step, Write&Read Registers, Write&Read Memory. It returns

to its caller either when the command completes or when a

breakpoint occurs (or a DLL load). These commands and

notifications appear in a large structure whose address is passed

in WinDebug().

     WinDebug() was renamed CVWIN.DLL (and TDWIN.DLL) for Windows

3.1., all crackers should study it and get the maximum possible

documentation about it. As you will see in the following, it is

worth to study also TOOLHELP.DLL (what Microsoft would like you

to fiddle with) and INT_41h (the real debugging interface).

Interrupt handling under Windows

     Interrupt handling under Windows can be tricky: you need to

use Toolhelp (a rather scaring lobotomy for your programs) or to

have special code for Standard vs. Enhanced modes, because the

information on the stack of an interrupt or exception handler

differs between the two windows modes. In addition, some handlers

would be installed using INT_21h, while others are set up using

DPMI services. Toolhelp has quite a bit of internal code that

"cooks" the interrupts and sends them to you in an easily

digestible form.

     Remember that Windows uses GP faults as a "hacker" method

of doing ring transitions that are not allowed with legal 80x86

instructions: the virtual memory system of Enhanced mode is

implemented via the page fault.

Some tools for cracking windows (-> see lesson 9)

-----------------          DEBUGGERS

CVW and TDW         (you have to know the function's

                    segment:offset address beforehand in order

                    to crack a function)

WCB                 [Windows Codeback] by Leslie Pusztai (it's

                    a really cool tool!)

WDEB386             Microsoft's WDEB386 (clumsy, and requires a

                    second monitor)

Soft-Ice/Windows    best (BY FAR!) windows debugger! NuMega is

                    so good I am at times really sorry to crack

                    their products! [WINICE] is the single,

                    absolutely essential debugger and snooping

                    utility for windows crackers. Get it!

-----------------   POST MORTEM INSPECTORS

CORONER, etc.            (a lot of shareware)

MS-DrWatson              Old and clumsy

Borland's Winspector     THE BEST! It has the BUILDSYM utility

                         that allows the creation of a debug

                         .SYM file from an .EXE without debug

                         information.

-----------------         INSPECTORS

MS-Spy                   Old

Borland's WinSight       (Best one, select "Other")

MicroQuill's Windows DeMystifiers (from Jeff Richter):

     VOYEUR (hold SHIFT picking Message Selection), COLONEL,

     MECHANIC and ECOLOGIST

-----------------          SNOOPERS

[INFSPY.EXE], 231.424 bytes, version 2.05 28/8/1994 by Dean

Software Design, may be the more complete one.

[SUPERSPY.EXE], 24.576 bytes, 10,6,1994, quite handy for quick

informations.

[WINVIEW.EXE], 30.832 bytes, Version 3.00 by Scott McCraw, MS(c)

1990-1992, this is the old MS-Spy, distributed by MS

[TPWSPY.EXE], 9.472 bytes, quite primitive, but you get the

pascal source code with it.

->   INSIDE A WINDOWS '95 DEBUGGER

     You can debug a program at the assembly-language level

without any debugging information. The DOS [DEBUG] program does

that, allowing breakpoints and single-stepping, all of which

implies that the hardware must be cooperating. Back in the time

of the 4-MHz Z-80s, you used a debugger that plugged interrupt

op codes into the instruction stream to generate breakpoints.

     Nothing has changed. That's how you debug a program on a

80586 (=Pentium). The x86 architecture includes software

interrupts. The 1-byte op code xCC is the INT_03 instruction,

reserved for debuggers. You can put the INT_03 op code in place

of the program instruction op code where the break is to occur

and replace the original op code at the time of the interrupt.

In the 80386 and later, you can set a register flag that tells

the processor to generate a not-intrusive INT_01 instruction for

every machine instruction executed. That device supports single

stepping.

     The Win32SDK (Windows '95 software developer's kit) includes

functions that allow one program to launch another program and

debug it. The SDK's debug API takes care of how the interrupts

and interrupt vectors get managed. The logical consequence of

such an approach is that fewer and fewer people will be able to

know what's going on inside an application. The bulk of the

programmers -in few years time- will not be able any more to

reverse engineer an application, unless the few that will still

understand assembler-language do offer them the tools to do it.

Microsoft -it is evident- would like the programmers to use a

"black box" approach to programming, writing nice little "hallo

world" application and leaving to the engineers in Microsoft

alone the capacity to push forward (and sell) real programs that

are not toy application.

     The Win32 documentation seems vast, almost luxurious, until

you begin serious work and you discover its shortcomings, like

the fact that extended error codes are not documented, and

numerous APIs are documented either incorrectly or so poorly that

you must burn precious time testing them. What we definitely need

is to find some secret fellows inside Microsoft (like good old

Prometeus) that smuggles to the outside the real documentation

that the Microsoft engineers have reserved for themselves. If you

are reading this and do work for Microsoft, consider the

possibility of double-crossing your masters for the sake of

humanity and smuggle us the secret information.

     In windows '95 a debugger program launches a program to be

debugged by calling the _CreateProcess function, specifying in

an argument that the program is to be debugged. Then the debugger

program enters a loop to run the program. At the top of the loop

the debugger calls _WaitForDebugEvent.

     Each time _WaitForDebugEvent returns it sets indicators that

tell about the vent that suspended the program being debugged.

This is where the debugger traps breakpoints and single-step

exceptions. _WaitForDebugEvent fills in an event structure that

contains among other things the address that was interrupted end

the event that caused the interrupt.

     The debugger calls _GetThreadContext to get the running

context of the debugged program, including the contents of the

registers. The debugger can, as the result of cracker

interaction, modify these values and the contents of the debugged

program's memory.

     The debugger sets breakpoints by saving the op code at the

instruction to be intercepted and putting the INT_03 op code at

its place, it's always the same old marmalade. When the

breakpoint occurs, the debugger replaces the original op code in

the program's instruction memory, and decrements the interrupted

program counter in the saved context so that execution resumes

at the instruction that was broken.

     To single-step a program, the debugger sets a bit in the

context's flags register that tells the processor to generate an

INT_01 for every instruction cycle. When that interrupt occurs,

the debugger checks to see if the interrupted address is at a new

source-code line number. If not, the debugger continues

execution. Otherwise, the debugger displays the new line in the

IDE and waits for the cracker to take an action that resumes the

program.

     While the debugged program is suspended, the debugger

interacts with the cracker and provides full access to the

debugged program's context and memory. This access permits the

cracker to examine and modify part of the code.

     To resume the debugged program, the debugger resets the

program's context by calling _SetThreadContext and calls

_ContinueDebugEvent. Then, the debugger returns to the top of the

loop to call _WaitForDebugEvent again.

     To extract debug information from a Win32 executable file,

you must understand the format of that file (best thing to do,

to practice yourself, would be to reverse engineer small

programs). The executable file has two sections not found in

other executable files: ".stab" and ".stabstr". How nice that

they used names that suggest their purpose (nomen est omen).

You'll find them inside a table of fixed-length entries that

include entries for .text, .bss, .data and .idata. Inside these

sections the compilers put different parts of a program.

     There are several different formats for encoding debug

information in an executable file. Borland's Turbo Debugger  one

format. Microsoft's CodeView  another. The gnu-win32 port from

Cygnus the stab format, an acronym meaning "symbol table",

although the table contains much more than just symbol

information.

     The .stab section in a portable executable file is a table

of fixed-length entries that represent debugging information in

the stab format. The .stabstr section contains variable-length,

null terminated strings into which the .stab table entries point.

     The documentation for the stab format is available in text

format on the Cygnus ftp site (ftp.cygnus.com//pub/gnu-win32).

     Stabs contain, in a most cryptic format, the names and

characteristics of all intrinsic and user-defined types, the

memory address of every symbol in external memory and on the

stack, the program counter address of every function, the program

counter address where every brace-surrounded statement block

starts and ends, the memory address of line numbers within

source-code files, and anything else that a debugger needs. The

format is complex and cryptic because it is intended to support

any source-code language. It is the responsibility of a debugger

program to translate the stab entries into something meaningful

to the debugger in the language being debugged.

     Windows '95 invokes dozens of INT_21 services from 32-bit

code, including KERNEL32.DLL and possess Krn32Mutex, which

apparently controls access to certain parts of the kernel. Some

of the functions in KERNEL32 can be blocked by the Win16Mutex,

even though Microsoft says this isn't the case.

SO, I WANNA CRACK, WHAT SHOULD I DO?

     I'll show you a simple windows crack, so easy it can be done

without WINICE: let's take [WINPGP4.1.] (front-end for PGPing in

windows, by Geib - I must thank "Q" for the idea to work on this

crack).

     Using WCB you'll find out quickly that the "CONGRATULATIONS

your registration number is OK" and the "SORRY, your registration

number is not correct" data blocks are at the block starting at

36.38B8 (respectively at 36.38D5 and 36.3937), that relocs to

13.081B.

     Looking at 13.0000 and following code, you'll find a push

38D5 (68D538) and a push 3937 (683739) at 13.064D and 13.06AE.

     The road to the crack is now open, you just need to find and

"fool" the calling routines. You'll learn the exact procedures

for this kind of WINcracks in part 2 and 3 of -> Lesson 8. Let's

now have a look at the protection scheme (disassembly from WCB):

...

13.0E88   660FBF46F8     movsx     eax, word ptr [bp-08]

13.0E8D   668946F4       mov       [bp-0C], eax

13.0E91   668B46F4       mov       eax, [bp-0C]

13.0E95   6669C00A000300 imul      eax, 0003000A

13.0E9C   668946F0       mov       [bp-10], eax

13.0EA0   668B4606       mov       eax, [bp+06]

13.0EA4   663B46F0       cmp       eax, [bp-10]

13.0EA8   7505           jne       0EAF      <- beggar_off

13.0EAA   B80100         mov       ax, 0001  <- flag 1 = "Right!"

13.0EAD   EB04           jmp       0EB3      <- and go on

beggar_off:

13.0EAF   33C0           xor       ax,ax     <- flag 0 = "Nope!"

13.0EB1   EB00           jmp       0EB3      <- and go on

     I want you to have a good look at this protection scheme.

IT'S THE SAME OLD SOUP! You do remember lesson 3 and the

protection schemes of the old DOS stupid games of the '80s, don't

you? IT'S THE SAME OLD SOUP! In this "up-to-date" "new" windows

application, in WINPGP version 4.1 of 1995/1996, exactly the same

kind of protection is used to "conceal" the password!

A)   compare user input with memory echo

B)   beggar off if not equal with AX=0

C)   go on if equal with AX=1... how boring!

     Besides, look at all the mov eax, and  eax, moves preceding

the compare! That's a typical pattern for these "number_password"

protections! I wrote (years ago) a little crack utility that

searches for code blocks with a "66" as first instruction_byte

repeating in four or more consecutive instructions and it still

allows me to crack more than half of these windows password smuts

in less than three seconds flat. The IMUL instruction creates the

"magic" number, and if you give a closer look at the mathematical

part of the "conceal" routine, it could help you to crack

analogous schemes used in order to protect the "Instant access"

(c) & (tm) time_crippled software :=)

     Now you could crack the above code in 101 different ways,

the most elegant one would probably substitute je 0EAF (or jZ

0EAF, that's the same) to the jne 0EAF at 13.0EA8. You just write

a 74 at the place of the 75, like you did for the cracks in

1978... how boring: it's really the same old soup! (But you'll

see some new tricks in the next lessons).

Well, that's it for this lesson, reader. Not all lessons of my

tutorial are on the Web.

     You 'll obtain the missing lessons IF AND ONLY IF you mail

me back (via anon.penet.fi) with some tricks of the trade I may

not know that YOU discovered. Mostly I'll actually know them

already, but if they are really new you'll be given full credit,

and even if they are not, should I judge that you "rediscovered"

them with your work, or that you actually did good work on them,

I'll send you the remaining lessons nevertheless. Your

suggestions and critics on the whole crap I wrote are also

welcomed.

                                E-mail +ORC

                         +ORC [e-mail]